home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Sep 90 / MacApp.Tech$ 9⁄14⁄90 / 1953-Where to call focus?-Sep90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  3.0 KB  |  63 lines  |  [TEXT/GEOL]
  1. Item    7399224                         8-Sept-90        23:02PDT
  2.  
  3. From:   PEMD                            CH DEV PEMD Group, Zurich,IDV
  4.  
  5. To:     KNEPPER                         Knepper, Christopher
  6.  
  7. cc:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    Where to call focus?
  10.  
  11. Dear Chris,
  12.  
  13. I've been carefully considering your link of 5-Sept-90 and attempting to apply
  14. "always focus before drawing", rather than thinking "where was the focus last
  15. set".  I am also interested in having my code be as consistent with
  16. object-oreinted principles as possible.
  17.  
  18. I'm actually not clear on how to implement this.  I want to get to the question
  19. "where to call focus?" and to  do that consider a situation where a menu
  20. command results in some drawing action, but this drawing action does not alter
  21. the document.  Instead, it alters the way the view in the active, front window
  22. renders the document.
  23.  
  24. More specifcally, let's say that the document conatins numerical demographic
  25. data on population, population growth rates, life expectancy, etc. for various
  26. countries of the world over the last 10 years..  A part of this data (i.e.
  27. document) is displayed in a view in which a country's population figures are
  28. shown in a line graph (e.g. population=f(years)) placed in a standard x-y
  29. coordinate system.  A view consists of many such line graphs with a set of axes
  30. (population on the Y-axis and years on the X-axis).
  31.  
  32. The user now chooses a menu command "Clear", which erases all graphs from the
  33. view, but leaves the axes, enabling him to enter a fresh set of countries.  Now
  34. lets go back to the problem in my original set of memos on the "Drawing
  35. Problem".  There are many such views in many such windows on the the screen
  36. (one view to a window).  The window of interest is the front, active window and
  37. complete screen updating has occured.  This window is the first drawn, but the
  38. last window drawn is the one on which drawing is now focused.  The user now
  39. selects "Clear" from the menu.  Where should focus be called?  The "Clear"
  40. command's DoIt method calls Eraserect which without a call to Focus is directed
  41. at the last window drawn, not the front active window.  The DoIt method could
  42. of course call Focus on its view and such a call would be consistent with
  43. "always focus before drawing".
  44.  
  45. Such a strategy would insert Focus calls throughout the code, in this case,
  46. whenvever the view was changed without a corresponding change to the document.
  47. This was indeed my initial strategy when I first read your links on my drawing
  48. problem.  I then elected to put a single Focus call at the beginning
  49. myView.DoMenuCommand, because all such code (except one) that changed the view
  50. without changing the document was called from  myView.DoMenuCommand.
  51.  
  52. Do you see this as contrary to object-oreinted principles?  I do not have any
  53. particular fidelity to principles as such, and object-oreinted thinking has
  54. been so useful that I wanted to stay as firmly within the framework as
  55. possible.
  56.  
  57. Thanks for time.
  58.  
  59. Regards,
  60. Ernie
  61.  
  62.  
  63.